Subject: Re: DateAndTime versus TimeStamp for Counter Discontinui

From: "Bill Kwan" <[email-masked]>
Date: Tue, 22 Oct 1996 16:23:16 +0000

Since AIW12 is in a couple of weeks, I will hold off raising this issue to 
Deirdre before then. We will schedule some time at the meeting to 
discuss the issue and hopefully get a working group concensus.  
Thanks. 

Regards,
Bill

>From:          "Bill Kwan" <[email-masked]>
>Organization:  Jupiter Technology, Inc
>To:            [email-masked], [email-masked]
>Date:          Mon, 30 Sep 1996 12:15:59 EST5EDT
>Subject:       Re: DateAndTime versus TimeStamp for Counter Discontinuities
>Priority:      normal

>Hi folks,

>Hopefully, we have had enough time to review BobM's proposal on 
>TimeStamps. Randy's position is that being a reviewer, he must 
>cite RFC1902 on how it should be done (even if he might secretly
>agree with Bob :-). He suggested that if the working group 
>feels strongly enough about the issue that we should
>get a ruling from Deirdre.

>Does the working group feel strongly enough about this? 
>Since we have had similar discussions on this subject before,
>if I don't hear anyone strongly objecting within the next two weeks,
>I will raise the issue to Deirdre.

>Regards,
>Bill

> Date:          Wed, 21 Aug 1996 10:03:03 -0400
> Reply-to:      [email-masked]
> From:          "R.E. (Robert) Moore (254-4436)" <[email-masked]>
> To:            [email-masked]
> Subject:       DateAndTime versus TimeStamp for Counter Discontinuities

> Since we spent so much time on this last fall, I'd like us to have
> a thorough discussion of it now.  Randy has said:
> 
> >|     Item:      29
> >|     Page:      23
> >|     Clause:    5
> >|     Qualifier: major
> >|     Rationale: RFC 1902 clause 7.1.6 requires that counters which can
> >|                experience discontinuities at times other than manage-
> >|                ment system re-initialization must identify an  object
> >|                of  type  TimeStamp  which  can be monitored to detect
> >|                such discontinuities.  This affects the definition  of
> >|                appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPort-
> >|                DynLsGoodXids, and appnPortDynLsBadXids.
> >|
> >|     Proposal:  Add an appnPortStartedTimeStamp object to satisfy this
> >|                requirement.
> >|
> >|BobM> This comment seems correct to me.  Do we want to add another
> >|BobM> time stamp for these counters (presumably in our usual
> >|BobM> DateAndTime format)?
> >
> >RFC 1902 clause 7.1.6 second paragraph requires a TimeStamp syntax.
> >(One can argue whether that's really the best representation, but 1902
> >is pretty explicit on this point.)
> 
> I think the following case can be made for our use of the DateAndTime
> syntax for our discontinuity indicators:
> 
> 1.  DateAndTime does a better job of indicating counter discontinuities
>     than TimeStamp does.  If an agent follows the same script each time
>     it comes up, then a link or port might come up at exactly the same
>     time relative to when sysUpTime was started over and over.  (This is
>     more likely if the agent, as some agents do, implements TimeTicks
>     objects by counting whole seconds and multiplying by 100.)  Thus a
>     TimeStamp might fail to signal a discontinuity, when a DateAndTime
>     would.
> 
> 2.  A Management Station will use a DateAndTime to identify a
>     discontinuity in exactly the same way it uses a TimeStamp:  retrieve
>     it with the counters, and see if it matches the value that was
>     retrieved before.  If the two values match, subtract the counter
>     values and treat the difference as significant.  If they don't match,
>     take the counter discontinuity path.
> 
> 3.  While it's unreasonable for RFC-1902 to require all SNMP agents to
>     support DateAndTime, the agents *we* deal with are in, or closely
>     associated with, APPN nodes, which must support date-and-time
>     stamping anyway.  Thus it's reasonable for us to specify DateAndTime
>     discontinuity indicators.
> 
> Summary:  DateAndTime provides a better indication of counter
> discontinuities than TimeStamp does, our agents can provide it, and it
> doesn't cause Management Stations any additional work.  Thus we should
> be able to use it.  (I really don't think the authors of RFC-1902
> intended to be placing an *upper* bound here on how well an agent could
> identify counter discontinuities; my guess is that they just didn't
> consider using DateAndTime for this purpose.)
> 
> If the rest of the WG / SIG agrees with this argument, maybe we can ask
> Randy whether we should open a defect against RFC-1902, record a
> deviation from RFC-1902, or do something else.
> 
> Bob Moore, IBM Network Management Architecture
> 
>